home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20000114-20000217 / 000170_news@columbia.edu _Fri Jan 28 11:58:27 2000.msg < prev    next >
Internet Message Format  |  2020-01-01  |  7KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id LAA13168
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 28 Jan 2000 11:58:27 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id LAA01314
  7.     for kermit.misc@watsun.cc.columbia.edu; Fri, 28 Jan 2000 11:31:28 -0500 (EST)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Subject: Re: Case Study #10: Atomic File Movement
  11. Date: 28 Jan 2000 16:31:26 GMT
  12. Organization: Columbia University
  13. Message-ID: <86sg8u$190$1@newsmaster.cc.columbia.edu>
  14. To: kermit.misc@columbia.edu
  15.  
  16. In article <nJLJ3X13aW$a@cc.usu.edu>, Joe Doupnik <jrd@cc.usu.edu> wrote:
  17. :
  18. : ... But there is that opening where bytes get swapped wrong in a
  19. : buffer deep down in the hardware and by chance the CRC check is ok.
  20. :
  21. Swapped bytes are not that uncommon.  Some years ago, we discovered that our
  22. own terminal servers had this problem under heavy load.  Checksums do not
  23. catch swapped bytes; CRCs do (except perhaps few pathological cases).
  24. C-Kermit 7.0 and K95 use CRCs by default.
  25.  
  26. As Joe says, if you are transferring files with Kermit over a TCP/IP
  27. connection that has bugs in it and delivers TCP packets to the wrong
  28. session, then confusion over Kermit packets, while astronomically
  29. improbable, is indeed possible, but (as Joe also says) it's the least of
  30. your problems.  If TCP is delivering packets to the wrong program, think
  31. what must be happening to your passwords and credit card numbers as you surf
  32. the web!  In any case, it would be unlikely that you could even log in to
  33. a host and begin a Kermit transfer under such conditions.
  34.  
  35. At least Kermit provides several layers of protection on top of TCP/IP:
  36. CRCs, sequence numbers, packet framing, and the finite state automaton of
  37. the protocol engine, which requires legal sequences of events that tend
  38. not to occur by chance.  Other TCP/IP applications, such as FTP and Telnet,
  39. do no error checking at all; they simply assume an error-free connection.
  40. If the underlying TCP connection is faulty, FTP and Telnet will not detect
  41. it, and certainly will not recover from it.
  42.  
  43. : What I am saying is, guarantees can't be absolute.
  44. :
  45. That's true.  The fact that some event has one chance in a trillion of
  46. taking place does not guarantee it won't happen to you.  But we base almost
  47. everything we do on probabilities -- the chances of a car wreck, a plane
  48. crash, of getting botulism from a jar of peanut butter, or that the PC we
  49. sit in front of every day will explode in our faces.
  50.  
  51. : Please do check your SCSI bus and RAID controller cache memory, and
  52. : type more carefully next time.
  53. :
  54. This is another important point.  The best protocol in the world won't
  55. protect your data from interrupt conflicts and similar problems on its
  56. way from your computer's memory (after the protocol is finished with it)
  57. to the disk.
  58.  
  59. In many cases we have easy ad-hoc ex-post-facto integrity checks at our
  60. disposal.  If we have transferred an executable program, can we execute it?
  61. If we have transferred a Microsoft Word document, can we load it into Word
  62. and does it look about right (i.e. not like Klingon).  If we transferred C
  63. source code, does it compile?  These are not guarantees; they can give
  64. false positives, but you'll rarely get a false negative :-)
  65.  
  66. In general, the chances that a structured computer file has been damaged in
  67. such a way that its associated application won't notice are relatively
  68. small -- not zero, but small.  Plain text is the most vulnerable, since it
  69. has no associated application.  It is for humans to read.  If the word
  70. "not" was dropped out of a sentence, how would we know?
  71.  
  72. When you are transferring a file between like platforms, they often have
  73. a utility in common that generates CRCs, checksums, or ciphers over a whole
  74. file; in such cases, that utility can be run on the file before and after
  75. transfer and the result checked for equality.  Examples include the Unix
  76. 'sum' and 'md5sum'.
  77.  
  78. Kermit itself offers you a platform-independent check: a 16-bit CRC over the
  79. entire file.  It is not computed unless you ask for it, since it impacts
  80. performance a bit.  But in C-Kermit, MS-DOS Kermit, and Kermit 95 you can:
  81.  
  82.   SET TRANSFER CRC-CALCULATION ON
  83.  
  84. Then after a file has been transferred, each Kermit's \v(crc16) variable
  85. contains the file's CRC (as a decimal numeric string).  This check can be
  86. used only for binary-mode transfers since text-mode transfers, by
  87. definition, change the file and so the before-and-after CRCs can not be
  88. expected to agree.  Here's an example using a client/server connection that
  89. works no matter what platforms are involved (adapted from "Using C-Kermit",
  90. 2nd Ed, page 361):
  91.  
  92.   set transfer crc on           ; Required in C-Kermit 7.0 and K95 1.1.17
  93.   set file type binary
  94.   send mission-critical-data.bin
  95.   if fail exit 1 Transfer Failed
  96.   query kermit crc16
  97.   if not = \v(query) \v(crc16) exit 1 CRC mismatch
  98.  
  99. (The server must also be told to "set transfer crc on".)  Again, this is
  100. not a guarantee but it's a further check.  The probability that Kermit's
  101. per-packet checking fails to catch an error AND the independent per-file
  102. CRCs will match in spite of an error is the product of the separate
  103. probabilities.  So if the first is 0.0000002 and the second is 0.0000003,
  104. the probability of both is 0.0000000000006.
  105.  
  106. You can add further and further checks if you wish.  Are the lengths the
  107. same?
  108.  
  109.   query kermit size(mission-critical-data.bin)
  110.   if not = \v(query) \fsize(mission-critical-data.bin) exit 1 Size mismatch
  111.  
  112. The ultimate test might be to transfer the file back to the source platform
  113. and compare the result byte for byte with the original.  But even this is
  114. no guarantee since it won't necessarily catch systematic errors, and there
  115. is always the minute possibility that an undetectable random error will
  116. occur at precisely the same spot in both transfers, in such a way that the
  117. second one "corrects" the first.  But what is the chance this will happen
  118. AND the all the other checks also fail to catch an error?
  119.  
  120. The point of all this is that you can safely place more trust in Kermit than
  121. you place in other well-known data transfer applications whose integrity you
  122. wouldn't think to question, such as FTP.  But if you don't trust it, a wide
  123. range of tools and tests are available to boost the confidence level.  But
  124. as Joe says, there can be no absolute guarantees.
  125.  
  126. - Frank